* Never change the connection state except in response to user input.

* 'advice' level connection pref values are:
  0 - none at all, the user knows every bit of the system
  1 - little reminders, like No such command: '...'. (Type 'help' for help.)
  2 - hints on what to do, like the login menu
  3 - explanations of everything

* $self->can_see($self) is how you test for blindness etc.

* Do not use overloading; it's slow.

* ALWAYS provide an explicit return value in a subroutine, even if it's just "return;". Also, be wary of a subroutine which may return either a single value or () in list context, as it can confuse hash construction.

* If an object field is a reference to a data structure (e.g. array, hash), then one should always call $obj->mutable_val($field) before modifying the structure, to make sure you do not modify the default value, and to mark the object dirty in the database.

* The MScheduler->mudclock method returns a value which is of unknown precision, but will always increase at 1.00 per mud-time second. The only time the absolute value of this number is useful is in computing the MUD's calendar.

* Processing of SX output must be done immediately; for example, the 'destroy' command produces a message that the object has been destroyed, then destroys it - this would not work if the SX were not processed immediately upon 'send'.

* mpMUD _should_ be able to run on any platform that supports Perl 5; known to work are:
  * Mac OS 9 / MacPerl 5.2.0r4 or 5.2.1a1
  * Linux (Red Hat)
  * Windows 98
  * Darwin (Mac OS X)

* A die() inside of handling a command may send a message to the player by prepending "CFAIL:" to the message. This is useful for utility subroutines inside of command handlers, e.g. object_scan and bp_assert.

* Containers' "cnt_interior" value specifies maximum VOLUME, but not weight. Weight limits are handled by weightlimit.mod.

* Use a bare block for aborting object calls
  { ($obj or last)->method(); }

* All Perl modules that are components of mpMUD should be designed so that they do not care about being compiled more than once. Initialization of variables and such should be handled in the _initialize method.

* If an if/elsif/elsif/... structure gets long and hard to read, place a blank line before each "} elsif (..."

* In an if/elsif/elsif/... where each block is only one line long, format it as:
     if (...) { ... }
  elsif (...) { ... }
   else       { ... }
The last line may be formatted as
   else {
    ...
  }
if appropriate.